Systems and methods for service availability determination in packet networks

ABSTRACT

Service availability determination systems and methods include determining availability of a packet service in a Maintenance Interval (MI) based on frame loss measurements in short intervals Δt and marking each Δt as available or unavailable based on the frame loss measurements and an associated Frame Loss Ratio (FLR) threshold, wherein each Δt is a High Loss interval (HLI) when exceeding the FLR threshold; utilizing a sliding window of size n, n being an integer, to determine whether the packet service is available or unavailable; and utilizing an extension period after an end of the MI with the sliding window to ensure all Δt&#39;s in the MI are marked as available or unavailable.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to packet networking. Moreparticularly, the present disclosure relates to systems and methods forservice availability determination in packet networks.

BACKGROUND OF THE DISCLOSURE

In Ethernet networks, various techniques are utilized for Operations,Administration, and Maintenance (OAM) monitoring including G.8013/Y.1731(August 2015) “Operations, administration and maintenance (OAM)functions and mechanisms for Ethernet-based networks,” the contents ofwhich are incorporated by reference herein. There are varioustechniques, performance monitoring tools, and metrics used to quantifyan Ethernet service including whether or not the service meets a ServiceLayer Agreement (SLA). Metro Ethernet Forum (MEF) TechnicalSpecification 10.3 “Ethernet Services Attributes Phase 3” October 2013,the contents of which are incorporated by reference herein, describes inSec. 8.8.4 a technique for a one-way availability performancemeasurement for an Ethernet Virtual Circuit (EVC). This availabilityperformance measurement is one such important metric. As per MEF 10.3,service availability of given service can be computed by measuring theFrame Loss Ratio (FLR) for short intervals called Δt's within anAvailability Measurement Interval (AMI). As an example, a serviceprovider can define the Availability Performance to be measured over amonth and the value for the Availability Performance objective to be 95%for one Class of Service (COS). Again, per MEF 10.3, Δt state (i.e.,available or unavailable) is marked using a sliding window algorithm.The availability performance measurement in MEF 10.3 has accuracyproblems. First, there is inaccuracy in the calculation of serviceavailability due to an ignored Δt at the end of each AMI. Second, theinaccuracy can be worse such as due to a scenario where a few High LossInterval (HLI) are present in a Maintenance Interval (MI) causing theentire MI to be marked as unavailable if this MI starts incorrectly inthe unavailable state because of ignored Δt at the end of the previousMI. Third, there can be an inaccurate transition of service availabilitystate. These inaccuracies lead to scenarios where determinedavailability is significantly different from the actual availability.

BRIEF SUMMARY OF THE DISCLOSURE

In an embodiment, a service availability determination methodimplemented in a packet network element includes determiningavailability of a packet service in a Maintenance Interval (MI) based onframe loss measurements in short intervals Δt and marking each Δt asavailable or unavailable based on the frame loss measurements and anassociated Frame Loss Ratio (FLR) threshold, wherein each Δt is a HighLoss Interval (HLI) when exceeding the threshold; utilizing a slidingwindow of size n, n being an integer, to determine whether the packetservice is available or unavailable; and utilizing an extension periodafter an end of the MI with the sliding window to ensure all Δt's in theMI are marked as available or unavailable. The service availabilitydetermination method can further include determining availability of thepacket service between two successive MI's which is separated by arepetition time, wherein second MI is inheriting availability state fromthe previous MI. The service availability determination method canfurther include determining availability over a time period greater thanthe MI and the second MI based on the availability determined in atleast the MI and the second MI. The extension period is between 0 and(n−1) times a length of each Δt. At an end of the MI, if a currentavailability state is unavailable and the last Δt is not an HLI, theextension period can be utilized until there is an HLI interval or n−1Δt's allowing a last Δt of the MI to be marked as available. At an endof the MI, if a current availability state is available and the last Δtis an HLI, the extension period can be utilized until there is a non-HLIinterval or n−1 Δt's allowing a last Δt of the MI to be marked asunavailable. The frame loss measurements can be compliant toG.8013/Y.1731.

In another embodiment, a packet network element includes one or moreports; a switching fabric configured to switch packets between the oneor more ports; and a controller configured to determine availability ofa packet service in a Maintenance Interval (MI) based on frame lossmeasurements in short intervals Δt and marking each Δt as available orunavailable based on the frame loss measurements and an associated FrameLoss Ratio (FLR) threshold, wherein each Δt is a High Loss Interval(HLI) when exceeding the IFR threshold, utilize a sliding window of sizen, n being an integer, to determine whether the packet service isavailable or unavailable, and utilize an extension period after an endof the MI with the sliding window to ensure all Δt's in the MI aremarked as available or unavailable. The controller can be furtherconfigured to determine availability of the packet service between twosuccessive MI's which is separated by a repetition time, wherein secondMI is inheriting availability state from the previous MI. The controllercan be further configured to determine availability over a time periodgreater than the MI and the second MI based on the availabilitydetermined in at least the MI and the second MI. The extension period isbetween 0 and (n−1) times a length of each Δt. At an end of the MI, if acurrent availability state is unavailable and the last Δt is not an HLI,the extension period can be utilized until there is an HLI interval orn−1 Δt's allowing a last Δt of the MI to be marked as available. At anend of the MI, if a current availability state is available and the lastΔt is an HLI, the extension period can be utilized until there is anon-HLI interval or n−1 Δt's allowing a last Δt of the MI to be markedas unavailable. The frame loss measurements can be compliant toG.8013/Y.1731.

In a further embodiment, a packet network includes a first networkelement which is a first Maintenance End Point (MEP); and a secondnetwork element which is a second MEP communicatively coupled to thefirst MEP, wherein availability of a packet service between the firstMEP and the second MEP is determined in a Maintenance Interval (MI)based on frame loss measurements in short intervals Δt and marking eachΔt as available or unavailable based on the frame loss measurements andan associated Frame Loss Ratio (FLR) threshold, wherein each Δt is aHigh Loss Interval (HLI) when exceeding the FLR threshold, wherein asliding window of size n, n being an integer, is utilized to determinewhether the packet service is available or unavailable, and wherein anextension period is utilized after an end of the MI with the slidingwindow to ensure all Δt's in the MI are marked as available orunavailable. Availability of the packet service is also determinedbetween two successive MI's which is separated by a repetition time,wherein second MI is inheriting availability state from the previous MI.Availability over a time period greater than the MI and the second MI isdetermined based on the availability determined in at least the MI andthe second MI. The extension period is between 0 and (n−1) times alength of each Δt. At an end of the MI, if a current availability stateis unavailable and the last Δt is not an HLI, the extension period canbe utilized until there is an HLI interval or n−1 Δt's allowing a lastΔt of the MI to be marked as available. At an end of the MI, if acurrent availability state is available and the last Δt is an HLI, theextension period can be utilized until there is a non-HLI interval orn−1 Δt's allowing a last Δt of the MI to be marked as unavailable.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated and described herein withreference to the various drawings, in which like reference numbers areused to denote like system components/method steps, as appropriate, andin which:

FIG. 1 is a flowchart of a process for determining Δ_((i,j))(Δt_(k))which defines availability/unavailability of a time interval Δt_(k) in aone-way Availability Performance for an Ethernet Virtual Circuit (EVC);

FIG. 2 is a block diagram of an example availability calculation;

FIG. 3 is a block diagram continuing the example availabilitycalculation of FIG. 2 illustrating a second Maintenance Interval (MI);

FIG. 4 is a block diagram continuing the example availabilitycalculation of FIG. 2 illustrating another second MI;

FIG. 5 is a flowchart of an accurate service availability determinationprocess in packet networks;

FIG. 6 is a network diagram of an example network utilizing Ethernet OAMmechanisms; and

FIG. 7 is a block diagram of an example implementation of a networkelement.

DETAILED DESCRIPTION OF THE DISCLOSURE

In various embodiments, the present disclosure relates to systems andmethods for service availability determination in packet networks. Thesystems and methods address significant inaccuracies in the MEF 10.3one-way availability performance measurement for an Ethernet VirtualCircuit (EVC). Advantageously, the systems and methods enable anEthernet service to be reliably measured by eliminating the inaccuracycaused by ignoring frames exchanged towards an end of the MI. Withaccurate measurements, Ethernet services are properly marked asavailable or unavailable thereby improving network operation withrespect to restoration, improving customer experience, etc.

One-Way Availability Performance for an EVC

Availability Performance is the percentage of time within a specifiedtime interval during which the Service Frame loss is small (i.e., belowa configured threshold). As an example, a service provider can definethe Availability Performance to be measured over a month and the valuefor the Availability Performance objective to be 99.9%. In a month with30 days and no Maintenance Interval, this objective will allow theservice to be unavailable for approximately 43 minutes out of the wholemonth.

Informally, Availability Performance is based on Service Frame lossduring a sequence of consecutive small time intervals. This can be basedon an Ethernet frame loss measurement (ETH-LM) or Ethernet syntheticframe loss measurement (ETH-SLM) from G.8013/Y.1731 or the like. Whenthe previous sequence was defined as Available, if the frame loss ishigh for each small time interval in the current sequence, then thesmall time interval at the beginning of the current sequence is definedas unavailable; otherwise, it is defined as available. On the otherhand, when the previous sequence was defined as unavailable, if frameloss is low for each small time interval in the current sequence, thenthe small time interval at the beginning of the current sequence isdefined as available; otherwise, it is defined as unavailable.

The formal definition for the Availability Performance is a follows:

For a time interval T, and a given Class of Service Name, Availabilityfrom ingress User-Network Interface (UNI) i to egress UNI j is based onthe following three parameters:

Δt is a time interval much smaller than T,

C is a frame loss ratio threshold which if exceeded suggestsunavailability, and

n is the number of consecutive small time intervals, Δt, over which toassess availability.

Each Δt_(k) in Tis defined to be either “available” or “unavailable” andthis is represented by A_((i,j))(Δt_(k)) where A_((i,j))(Δt_(k))=1 meansthat Δt_(k) is available and A_((i,j))(Δt_(k))=0 means that Δt_(k) isunavailable.

The definition of A_((i,j))(Δt_(k)) is based on the frame loss ratiofunction, flr_((i,j))(Δt_(k)), which is defined as follows:

Let I_(Δt) ^((i,j)) be the number of ingress Service Frames that meetvarious conditions (which are described on page 35 of MEF 10.3). LetE_(Δt) ^((i,j)) be the number of unique (not duplicate) egress ServiceFrames where each Service Frame is the first unerrored egress ServiceFrame at UNI j that results from the Service Frame counted in I_(Δt)^((i,j)).

Then

${{flr}_{({i,j})}\left( {\Delta\; t_{k}} \right)} = \left\{ {\begin{matrix}\left( \frac{I_{\Delta\; t}^{({i,j})} - E_{\Delta\; t}^{({i,j})}}{I_{\Delta\; t}^{({i,j})}} \right) & {{{if}\mspace{14mu} I_{\Delta\; t}^{({i,j})}} \geq 1} \\0 & {otherwise}\end{matrix}.} \right.$

Δt₀ is the first short time interval agreed by the Service Provider andSubscriber at or around the turn-up of the EVC. A_((i,j))(Δt_(k)) isdefined by a process 10 illustrated in a flowchart in FIG. 1.

An alternate way of expressing A_((i,j))(Δt_(k)) for k=0 is:

${A_{({i,j})}\left( {\Delta\; t_{o}} \right)} = \left\{ \begin{matrix}0 & {{{{if}\mspace{14mu}{{flr}_{({i,j})}\left( {\Delta\; t_{m}} \right)}} > C},{{{for}\mspace{14mu}{all}\mspace{14mu} m} = 0},1,\ldots\mspace{14mu},{n - 1}} \\1 & {otherwise}\end{matrix} \right.$

And for k=1, 2, . . . .

${A_{({i,j})}\left( {\Delta\; t_{k}} \right)} = \left\{ \begin{matrix}0 & \begin{matrix}{{{{if}\mspace{14mu}{A_{({i,j})}\left( {\Delta\; t_{k - 1}} \right)}} = {{1\mspace{14mu}{and}\mspace{14mu}{{flr}_{({i,j})}\left( {\Delta\; t_{m}} \right)}} > C}},} \\{{{{for}\mspace{14mu}{all}\mspace{14mu} m} = k},{k + 1},\ldots\mspace{14mu},{k + n - 1}}\end{matrix} \\1 & \begin{matrix}{{{{if}\mspace{14mu}{A_{({i,j})}\left( {\Delta\; t_{k - 1}} \right)}} = {{0\mspace{14mu}{and}\mspace{14mu}{{flr}_{({i,j})}\left( {\Delta\; t_{m}} \right)}} \leq C}},} \\{{{{for}\mspace{14mu}{all}\mspace{14mu} m} = k},{k + 1},\ldots\mspace{14mu},{k + n - 1}}\end{matrix} \\{A_{({i,j})}\left( {\Delta\; t_{k - 1}} \right)} & {otherwise}\end{matrix} \right.$

The availability for Δt_(k) is based on the FLR during the shortinterval and each of the following n−1 short intervals and theavailability of the previous short time interval. In other words, asliding window of width nΔt is used to determine availability.

Further, a Maintenance Interval (MI) is a time interval agreed to by theService Provider and Subscriber during which the service may not performwell or at all. The MI should be excluded from the AvailabilityPerformance.

Problem Description

Again, in networks, the performance of a service is monitored usingG.8013/Y.1731 performance monitoring tools where various metrics aremeasured/calculated to determine whether a service meets the SLA or not.Availability is one such important metric. As described herein, per MEF10.3, service availability of given service can be computed by measuringthe FLR for short intervals called Δt's within an AvailabilityMeasurement Interval (AMI). As an example, a service provider can definethe Availability Performance to be measured over a month and the valuefor the Availability Performance objective to be 95% for one Class ofService (CoS).

Δt could be High Loss Interval (HLI), i.e., 0 (when Δt's FLR>ThresholdFLR) and Non-HLI, i.e., 1 (when Δt's FLR≤Threshold FLR).

Δt state, i.e., available or unavailable, is marked using sliding windowalgorithm which slides over the next (n−1) Δt's in given window to markthe 1st Δt and so on (‘n’ is the window size). The availability for aparticular class of service name from UNI i to UNI j for a time intervalT is based on the percentage of Δt's available. Thus, whether aMaintenance Entity is in available time or unavailable time for a givenservice cannot be determined until a period of n Δt (the AvailabilityWindow) has passed. FIG. 1 illustrates the state transitions and markingof each Δt depending upon the loss results for next (n−1) Δt's.

FIG. 2 is a block diagram of an example availability calculation. Thereis an AMI 10 which can be 3 hours in this example with MI 12 being anhour with a delay between successive MI 12 (repetition-time) of an hour.The short measurement interval Δt can be 10 sec. and the sliding windowsize (n) can be 20. In this example, in the MI #1 12, the first 321 Δtis marked as available, and a next 20 Δt are marked as unavailable.Finally, there are not enough Δt in the sliding window (n=20) to markthe state for the last 19 Δt. Hence, there is an unaccounted duration inthe AMI 10 of 19*10 sec.=190 sec. FIG. 2 illustrates some scenarioswhere the Δt state cannot be marked accurately due to insufficient Δt'sin a given sliding window. This has a large impact on the serviceavailability determination and can cause problems for SLA compliance.Specifically, the conventional service availability computation isinaccurate due to the ignored Δt's at the end of the AMI 10.

FIG. 3 is a block diagram continuing the example availabilitycalculation of FIG. 2 illustrating a second MI 12. Here, the first MI 12is as illustrated in FIG. 2 with the 19 Δt's ignored. A repetition time18 follows the first MI 12 and then the second MI 12 begins. Since thefirst MI 12 was concluded with an unavailable state, the second MI 12begins unavailable, namely the service is unavailable for 20 Δt's. Inthis example, there are a few HLI's in the second MI 12 causing 20consecutive non-HLI Δt's not to be encountered in the second MI 12 thusservice is unavailable for the entire second MI 12 or for 341 Δt's.

Service availability is computed for the AMI 10 based on the two MI 12,and 19 ΔT are ignored at the end of each MI 12 in this example as wellas the entire second. MI 12 being unavailable. Total number of Δt's withindications in the AMI 10 isTotal indicator in MI #1(341)+Total Indicator in MI #2(341)=682.Note, the total is 341 which is 360 minus 19. That is, each MI 12 is onehour, and each Δt is 10 sec., so each MI has 360 Δt's and with the last19 ignored, each MI 12 contributes 341 Δt's.

In a day, there will be 8 such AMI 10 (as each AMI is 3 hours). Hence,the total indicator in a day (24 hours) will be 682*8=5456. Now, basedon the first MI 12 and the second MI 12, the service availability for aday will be 5095 which is 5456 minus 20 minus 341. The SLA calculationhere is (5456−(20+341))/5456=93.384%. The ignored Δt's result in an SLAof 93.384% which violates the 95% SLA agreement.

FIG. 4 is a block diagram continuing the example availabilitycalculation of FIG. 2 illustrating another second MI 12. Considering theprevious example for service availability computation, i.e., in an hourof the MI 12, assume the service was down for 200 seconds accounted by20 Δt's. Since the previous MI was concluded with the state unavailable.The second MI 12 will start with state unavailable, and the service willremain unavailable until 20 consecutive non-HLI Δt's are observed.

Thus, the sliding window can cause a significant number of Δt's to beignored as illustrated in FIGS. 3-4.

Accurate Service Availability Determination in Packet Networks

To address the aforementioned problem, no Δt's are ignored due toinsufficient Δt's in a sliding window such that the percentagecalculation for the availability metric is more accurate. With theproposed solution, the total service indicator, i.e., the sum ofavailable and unavailable indicators is equal to a number of Δt's in agiven AMI 10. Whereas without this solution, the total service indicatoris less by m*(n−1) Δt's where m=No. of MI's in an AMI and n=window sizein the given AMI 10.

FIG. 5 is a flowchart of an accurate service availability determinationprocess 30 in packet networks. The process 30 includes an extension ofthe sliding window into the repetition time 18, i.e., service frame lossmeasurement Protocol Data Unit (PDU) will happen in the repetition time18 for a short duration to conclude the unaccounted Δt's from theprevious MI 12. This short duration is an extension period (X) thatcould range from 0≤X≤(n−1) Δt's where n is the sliding window size. Forexample, using the example values from above when n=20 and Δt is 10 sec.The extension period X could be up to 190 sec. In this manner, there isno scenario in the MI 12 where Δt's are ignored thereby leading to amore accurate availability determination.

The process 30 is implemented in a packet network element in a packetnetwork, to extend the MI 12 such that Δt's are not ignored due to themechanics of the sliding window. At the end of the MI 12, the currentavailability state (step 31) is either unavailable or available based onservice frame loss measurement in preceding Δt's and the sliding window.As described herein, the sliding window can cause Δt's to be ignored,and the process 30 ensures that no Δt's are ignored by extending the MI12 into the extension period X.

If the current availability state (step 31) is unavailable, and the lastΔt in the MI 12 is an HLI (step 32), the process 30 does not require theextension period X and the last Δt's are unavailable, i.e., it ispossible to determine the state of the remaining intervals in the MI 12(step 33) as the last Δt's in the MI 12 are all unavailable.

Now, if the current availability state (step 31) is unavailable, and thelast Δt in the MI 12 is not an HLI (step 32), the process 30 includestransmitting more loss frames until an HLI interval is determined oruntil (n−1) loss frames have been transmitted (step 34). Here, thecurrent availability state is unavailable, but the last Δt is not an HLImeaning there could be a state transition to available. Conventionally,these last Δt's would be ignored as described herein. However, theprocess 30 extends the MI 12 into the extension period X for up to (n−1)Δt to give the state a chance to change to available. In the extensionperiod X, if there is an HLI, then the extension period X ends as thestate remains unavailable (step 33). In the extension period X, if thereare no HLI's and (n−1) loss frames have been transmitted (step 34), thenthe state can transition to available (step 33). Thus, step 34 allows aproper determination of the unavailable state at the end of the MI 12.

Similarly, if the current availability state (step 31) is available andthe last Δt in the MI 12 is non-HLI (step 35), the process 30 does notrequire the extension period X and the last Δt's are available, i.e., itis possible to determine the state of the remaining intervals in the MI12 (step 33) as the last Δt's in the MI 12 are all available.

Now, if the current availability state (step 31) is available and thelast Δt in the MI 12 is an HLI (step 35), the process 30 includestransmitting more loss frames until a non-HLI interval is determined oruntil (n−1) loss frames have been transmitted (step 36). Here, thecurrent availability state is available, but the last Δt is an HLImeaning there could be a state transition to unavailable. Again,conventionally, these last Δt's would be ignored as described herein.However, the process 30 extends the MI 12 into the extension period Xfor up to (n−1) Δt to give the state a chance to change to unavailable.In the extension period X, if there is a non-HLI then the extensionperiod X ends as the state remains available (step 33). In the extensionperiod X, if (n−1) loss frames have been transmitted and no non-HLIinterval (step 36), then the state can transition to unavailable (step33). Thus, step 36 allows a proper determination of the available stateat the end of the MI 12.

Example Operation

The service availability is computed as (Total AvailableIndicator)/(Total accounted Indicator). Without the process 30, if19Δt's, i.e., (n−1) Δt's, are ignored, then the availability states ofthe next Δt is marked as unavailable. As described herein, when the Δt'sare ignored at the end of one MI 12, the first n (e.g., 20) Δt's in thenext MI 12 are marked as unavailable instead of accurately marked asavailable.

Now, this can lead to a significant difference in the actualavailability versus the calculated availability since this unavailablemarking of the first Δt in the next MI 12 is not necessarily accuratesince the Δt's are ignored in the first MI 12, Thus, the second MI 12will have an unavailable state for the first n Δt's until the state canbe changed to available.

For example, assume there are only two MI's 12 in a day and this exampledescribed herein would cause the loss of n Δt's in the second MT 12.This could lead to an SLA for the availability of 94% while the actualavailability was 99.6%, within the SLA. The process 30 allows theavailability to be accurately computed without wasting ignored Δt's.Further, the described problem can be even worse when serviceavailability is computed for a month. Also, inaccuracy in making thetransition from unavailable to available can even cause multiple AMIs tobe marked as unavailable. But with process 30, the described problem canbe completely resolved.

Network

FIG. 6 is a network diagram of an example network 100 utilizing EthernetOAM mechanisms. For illustration purposes, the network 100 includesthree interconnected network elements 102, 104, 106. The network 100utilizes Ethernet OAM mechanisms such as IEEE 802.1ag Connectivity FaultManagement (CFM), Y.1731, etc. Fundamental to CFM is the concept of aMaintenance Entity Group (MEG) or a Maintenance Association (MA), whichis the identified network transport construct spanning the variousnetwork nodes underlying a given service or set of services. CFM relieson well-defined messages (OAM PDUs) exchanged between the networkelements, specifically and in particular each End Point (MEP) thatprovides origination and termination of the service transport path(s)for a MEG or MA. The network elements 102, 104 are defined as an MEP. InCFM, an MEP is configured to source and sink OAM PDUs, i.e., source andsink within a single configured MD (Maintenance Domain), pass-thru if MDLevel is higher than the configured level for the MEP, and discard if MDLevel is lower. The MEPs 102, 104 are also configured to participate inperformance monitoring such as loss measurement, delay measurement, linktrace, loopback, etc. In a point-to-point network, there are two MEPnodes at the endpoints, and in other configurations, there may bemultiple MEP nodes. Also, a CFM domain having one or more MaintenanceIntermediate Point (MIP) nodes that may be bounded by a plurality of MEPnodes. In order that CFM frame flows are appropriately filtered so thatthey are processed only by the intended domain's nodes, the MEP/MIPpopulation of an Ethernet CFM network is configured appropriately.

The network element 106 is defined as a MIP which resides between MEPs,i.e., the MIP 106 is communicatively coupled between the MEPs 102, 104.A MIP is configured to process and forward CFM frames but does notinitiate CFM frames. Although a MIP does not initiate protocoltransactions, it does transmit Loopback Reply (LBR) and Linktrace Reply(LTR) messages in response to received Loopback Message (LBM) andLinktrace Message (LTM) messages respectively. As described herein, MEPand MIP terminology is used for nodes present at endpoints andintermediate points, respectively, in the network 100. Also, EthernetPath terminology is used to denote a point-to-point Ethernet connectionbetween two nodes, e.g., the connection being built using Virtual LocalArea Network (VLAN) cross connection or unicast Ethernet Media AccessControl (MAC) plus VLAN connection. Additionally, other types ofEthernet paths, such as, for example, Provider Backbone Bridging-TrafficEngineering (PBB-TE), MPLS-TP, and the like are also contemplated by thesystems and methods described herein.

The systems and methods contemplate implementation and operation innetworks, network devices, network elements, Virtual Network Functions(VNFs), etc. such as those compliant with IEEE 802.1ag-2007,G.8013/Y.1731, and/or MEF. Of note, IEEE 802.1ag-2007 and G.8013/Y.1731both relate to and define CFM for Ethernet OAM. Various terminologyutilized herein, such as MEP, MIP, CCM, PDU, etc. is common to each ofIEEE 802.1ag-2007, G.8013/Y.1731, MEF, etc. IEEE 802.1ag-2007 utilizesthe term Maintenance Association (MA) whereas G.8013/Y.1731 utilizesMaintenance Entity Group (MEG) for the same aspect. Those of ordinaryskill in the art will recognize while described herein as the MEG; theMEG could also be referred to as the MA 108. Generally, the MEG and MA108 relate to an administrative grouping relative to the MEPs 102, 104.

The network elements 102, 104, 106 are configured in an MA 108 whichenable a grouping of nodes in a maintenance group for OAM to be groupedon different spans. The MA 108 is a set of MEPs, each configured with asame unique MA ID code (UMC) and Maintenance Association Identifier(MAID) and Maintenance Domain (MD) level. The MA 108 may be thought ofas a full mesh a Maintenance Entities (MEs), the MEs including MEPs,MIPs, etc., with a set of MEPs configured therebetween. The network 100can also include a management system 110 communicatively coupled to thenetwork elements 102, 104, 106 through a data communications network112. The management system 110 can be a Network Management System (NMS),an Element Management System (EMS), a craft interface, etc. In anembodiment, the management system 110 is configured to provide OAMaccess to the network 100 as well as the provisioning of services andthe like.

Network Element

FIG. 7 is a block diagram of an example implementation of a networkelement 200. The network element 200 can be an Ethernet network switchfor illustration purposes, but those of ordinary skill in the art willrecognize the systems and methods described herein contemplate othertypes of network elements and other implementations. In this embodiment,the network element 200 includes a plurality of blades 202, 204interconnected via an interface 206. The blades 202, 204 are also knownas line cards, line modules, circuit packs, pluggable modules, etc., andgenerally refer to components mounted within a chassis, shelf, etc. of adata switching device, i.e., the network element 200. Each of the blades202, 204 may include numerous electronic devices and/or optical devicesmounted on a circuit board along with various interconnects includinginterfaces to the chassis, shelf, etc. Two example blades areillustrated with line blades 202 and control blades 204. The line blades202 generally include data ports 208 such as a plurality of Ethernetports. For example, the line blade 202 may include a plurality ofphysical ports disposed on an exterior of the blade 202 for receivingingress/egress connections. Additionally, the line blades 202 mayinclude switching components to form a switching fabric via theinterface 206 between all of the data ports 208 allowing data traffic tobe switched between the data ports 208 on the various line blades 202.The switching fabric is a combination of hardware, software, firmware,etc. that moves data coming into the network element 200 out by thecorrect port 208 to the next network element. In general, the switchingfabric may include switching units, or individual boxes, in a node;integrated circuits contained in the switching units; and programmingthat allows switching paths to be controlled.

The control blades 204 include a microprocessor 210, memory 212,software 214, and a network interface 216. Specifically, themicroprocessor 210, the memory 212, and the software 214 maycollectively control, configure, provision, monitor, etc. the networkelement 200. The network interface 216 may be utilized to communicatewith a management system such as a Network Management System (NMS),Element Management System (EMS), and the like. Additionally, the controlblades 204 may include a database 220 that tracks and maintainsprovisioning, configuration, operational data and the like. The database220 may include a management information base (MIB) 222 which mayinclude CFM objects. Further, the control blades 204 may include aSimple Network Management Protocol (SNMP) Agent 226 configured tooperate SNMPv2, SNMPv3, etc. or some other network managementcommunication protocol. In this exemplary embodiment, the networkelement 200 includes two control blades 204 which may operate in aredundant or protected configuration such as 1:1, 1+1, etc. In general,the control blades 204 maintain dynamic system information includingLayer two forwarding databases, protocol state machines, and theoperational status of the ports 208 within the network element 200.

It will be appreciated that some embodiments described herein mayinclude one or more generic or specialized processors (“one or moreprocessors”) such as microprocessors; Central Processing Units (CPUs);Digital Signal Processors (DSPs): customized processors such as NetworkProcessors (NPs) or Network Processing Units (NPUs), Graphics ProcessingUnits (GPUs), or the like; Field Programmable Gate Arrays (FPGAs); andthe like along with unique stored program instructions (including bothsoftware and firmware) for control thereof to implement, in conjunctionwith certain non-processor circuits, some, most, or all of the functionsof the methods and/or systems described herein. Alternatively, some orall functions may be implemented by a state machine that has no storedprogram instructions, or in one or more Application Specific IntegratedCircuits (ASICs), in which each function or some combinations of certainof the functions are implemented as custom logic or circuitry. Ofcourse, a combination of the aforementioned approaches may be used. Forsome of the embodiments described herein, a corresponding device inhardware and optionally with software, firmware, and a combinationthereof can be referred to as “circuitry configured or adapted to,”“logic configured or adapted to,” etc. perform a set of operations,steps, methods, processes, algorithms, functions, techniques, etc. ondigital and/or analog signals as described herein for the variousembodiments.

Moreover, some embodiments may include a non-transitorycomputer-readable storage medium having computer readable code storedthereon for programming a computer, server, appliance, device,processor, circuit, etc. each of which may include a processor toperform functions as described and claimed herein. Examples of suchcomputer-readable storage mediums include, but are not limited to, ahard disk, an optical storage device, a magnetic storage device, a ROM(Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM(Erasable Programmable Read Only Memory), an EEPROM (ElectricallyErasable Programmable Read Only Memory), Flash memory, and the like.When stored in the non-transitory computer-readable medium, software caninclude instructions executable by a processor or device (e.g., any typeof programmable circuitry or logic) that, in response to such execution,cause a processor or the device to perform a set of operations, steps,methods, processes, algorithms, functions, techniques, etc. as describedherein for the various embodiments.

Although the present disclosure has been illustrated and describedherein with reference to preferred embodiments and specific examplesthereof, it will be readily apparent to those of ordinary skill in theart that other embodiments and examples may perform similar functionsand/or achieve like results. All such equivalent embodiments andexamples are within the spirit and scope of the present disclosure, arecontemplated thereby, and are intended to be covered by the followingclaims.

What is claimed is:
 1. A service availability determination methodimplemented in a packet network element, comprising: determiningavailability of an Ethernet Virtual Circuit (EVC) in a MaintenanceInterval (MI) based on frame loss measurements in short intervals Δt andmarking each Δt as available or unavailable based on the frame lossmeasurements and an associated Frame Loss Ratio (FLR) threshold, whereineach Δt is a High Loss Interval (HLI) when exceeding the FLR threshold;utilizing a sliding window of size n, n being an integer, to determinewhether the EVC is available or unavailable; and utilizing an extensionperiod of time after an end of the MI with the sliding window to ensureall Δt's in the MI are marked as available or unavailable, wherein theextension period is between 0 and (n−1) times a length of each Δt. 2.The service availability determination method of claim 1, furthercomprising: determining availability of the EVC between two successiveMI's which is separated by a repetition time, wherein second MI isinheriting availability state from the previous MI.
 3. The serviceavailability determination method of claim 2, further comprising:determining availability over a time period greater than the MI and thesecond MI based on the availability determined in at least the MI andthe second MI.
 4. The service availability determination method of claim1, wherein, at an end of the MI, if a current availability state isunavailable and the last Δt is not an HLI, the extension period isutilized until there is an HLI interval or n−1 Δt's allowing a last Δtof the MI to be marked as available.
 5. The service availabilitydetermination method of claim 1, wherein, at an end of the MI, if acurrent availability state is available and the last Δt is an HLI, theextension period is utilized until there is a non-HLI interval or n−1Δt's allowing a last Δt of the MI to be marked as unavailable.
 6. Theservice availability determination method of claim 1, wherein the frameloss measurements are compliant to G.8013/Y.1731.
 7. A packet networkelement comprising: one or more ports; a switching fabric configured toswitch packets between the one or more ports; and a controllerconfigured to determine availability of an Ethernet Virtual Circuit(EVC) in a Maintenance Interval (MI) based on frame loss measurements inshort intervals Δt and marking each Δt as available or unavailable basedon the frame loss measurements and an associated Frame Loss Ratio (FLR)threshold, wherein each Δt is a High Loss Interval (HLI) when exceedingthe FLR threshold, utilize a sliding window of size n, n being aninteger, to determine whether the EVC is available or unavailable, andutilize an extension period of time after an end of the MI with thesliding window to ensure all Δt's in the MI are marked as available orunavailable, wherein the extension period is between 0 and (n−1) times alength of each Δt.
 8. The packet network element of claim 7, wherein thecontroller is further configured to determine availability of the EVCbetween two successive MI's which is separated by a repetition time,wherein second MI is inheriting availability state from the previous MI.9. The packet network element of claim 8, wherein the controller isfurther configured to determine availability over a time period greaterthan the MI and the second MI based on the availability determined in atleast the MI and the second MI.
 10. The packet network element of claim7, wherein, at an end of the MI, if a current availability state isunavailable and the last Δt is not an HLI, the extension period isutilized until there is an HLI interval or n−1 Δt's allowing a last Δtof the MI to be marked as available.
 11. The packet network element ofclaim 7, wherein, at an end of the MI, if a current availability stateis available and the last Δt is an HLI, the extension period is utilizeduntil there is a non-HLI interval or n−1 Δt's allowing a last Δt of theMI to be marked as unavailable.
 12. The packet network element of claim7, wherein the frame loss measurements are compliant to G.8013/Y.1731.13. A packet network element comprising: one or more ports; a switchingfabric configured to switch packets between the one or more ports; and acontroller configured to determine availability of an Ethernet VirtualCircuit (EVC) in a Maintenance Interval (MI) based on frame lossmeasurements in short intervals Δt and marking each Δt as available orunavailable based on the frame loss measurements and an associated FrameLoss Ratio (FLR) threshold, wherein each Δt is a High Loss Interval(HLI) when exceeding the FLR threshold, utilize a sliding window of sizen, n being an integer, to determine whether the EVC is available orunavailable, and utilize an extension period of time after an end of theMI with the sliding window to ensure all Δt's in the MI are marked asavailable or unavailable, wherein, at an end of the MI, if a currentavailability state is unavailable and the last Δt is not an HLI, theextension period is utilized until there is an HLI interval or n−1 Δt'sallowing a last Δt of the MI to be marked as available.
 14. The packetnetwork element of claim 13, wherein the controller is furtherconfigured to determine availability of the EVC between two successiveMI's which is separated by a repetition time, wherein second MI isinheriting availability state from the previous MI.
 15. The packetnetwork element of claim 14, wherein the controller is furtherconfigured to determine availability over a time period greater than theMI and the second MI based on the availability determined in at leastthe MI and the second MI.
 16. The packet network element of claim 13,wherein the extension period is between 0 and (n−1) times a length ofeach Δt.
 17. The packet network element of claim 13, wherein, at an endof the MI, if a current availability state is available and the last Δtis an HLI, the extension period is utilized until there is a non-HLIinterval or n−1 Δt's allowing a last Δt of the MI to be marked asunavailable.
 18. The packet network element of claim 13, wherein theframe loss measurements are compliant to G.8013/Y.1731.